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Linux is everyvvhere 


ə Most of the servers/ netvvorking equipments, 

ə 8070 of smartphones (Android) and 6596 of tablets, 
ə Entertainment systems (at home, cars, planes, ...): 
Mafority of loT devices. 


VVorld domination? 
No, because all products use outdated kernelsl 
Most products actually use forked kernels... 
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İs that a problem? 
Yes, it lovvers collaboration and leads to: 
ə Less features: All features do not get upstreamed / backported, 


ə Poorer Quality /Security: Less eyes per tree, fixes duplicated. 
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VVhy upstream is no good for vendors? 


Obiectives of making a product 


Get it as good as possible, and as quickly as possible 


Challenges vvith upstream 


ə Linux development not product-oriented: 


ə Releases not in sync vvith products, 
ə Conflicting obyectives: upstream vvants generic solutions 


ə Code sharing betvveen drivers mandated: AMD”s DAL/DC, 
ə Stable user ABls, no user-visible regressions, 
ə x İncreased dev. cost and Time-To-Market (TTM) 


Forked kernel? 
ə Full control over the code, 


ə None of the above challengesl 
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Obiectives 


VVhat should be done vvhen the next product comes? 


ə Re-use the previous product"s kernel? — technical debt, 


ə Rebase changes: can amount to a full re-implementation. 


Challenges vvith forked kernels 


ə You don £ get to shape the future of Linux: 
ə Out-of-tree code is not supported, 
ə Risk that internal changes break your features and userspace, 
ə Maintenance? 
Automotive products need 10-- years of maintenance, 
Linux Long-Term Support (LTS) maintained for 2 years, 
LTS releases only get fixes, no nevv features, 
Rebasing generates no revenue. 
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Obiectives 


Nice features of upstream development 


ə Non-regression of the user ABI makes updates easy, 


ə Never need to rebase: Others improve Linux and your code, 


Problem: Testing isn t freel 


ə Unless constantly tested, a feature gets accidentally broken, 


ə VVithout continuous testing, updating isn”t freel 
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Obiectives 


Reducing manual testing to 0 


ə Pre-merge testing is the best vvay to prevent regressions, 
ə Linux accepts about 8 changes per hour, in average, 


ə — all testing needs to be automatedl 


Problems vvith automated testing 


ə The full product needs to be tested, 
ə Requires system-level testing: 
ə — Need for better HVV-assisted test suitesl 
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Example of full product testing: Proyect trebble 


ə Android 8 de-couples the Ul from the vendor-provided system, 
ə The vendor interface is fully unit tested: 


ə — could be used for continuous integrationl 


VVhat can vve do on our side? 


ə Lead by example: provide regression free graphicsl 
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Hovv to provide regression-free graphics? 


Many dependencies 


ə İmprove the coverage of Open Source test suites to test: 
ə all graphic-related features of the kernel: 
ə all drivers. 
ə Validation HVV: 
ə Chamelium everyvvhere for testing DP//HDMI/VGA and sound 
ə Cİ platform: 
running the relevant test suites on all drivers, 
decentralized so as everyone can add platforms, 
developped and malintained by everyone, 


ə 
ə 
ə 
ə Controller instance hosted on fd.o? 


